Enterprise engineering systems, sometimes also referred to as spatial information management (SIM) systems, are computer-aided design (CAD) systems that facilitate two-dimensional (2D) and three-dimensional (3D) modeling and visualization. These systems are used in the design, construction, operation and modification of industrial plants, such as oil refineries and power generating stations, as well as other large, complex structures, such as high-rise buildings, off-shore drilling platforms, ships and mining and other materials handling facilities. With their graphical user interfaces (GUIs), enterprise engineering systems enable designers to lay out structural, piping, electrical, heating, ventilating and air conditioning (HVAC) and other complex systems and to visualize all or selected portions of a project at various stages of construction or operation.
Most modern enterprise engineering systems utilize object-oriented paradigms, in which software constructs called “objects” represent real-world items, such as beams, walls, floors, pipe runs, valves, conduits, switches, fans, ducts and the like. Some objects represent items, such as coordinate grid systems, that are mere conveniences to a designer and do not represent physical items.
Objects are typically implemented in software as data structures (ordered groups of data elements) that store information identifying the types of items represented, as well as information (such as length, width, color, capacity, etc., as appropriate for each item) about the specific item represented by each object. Objects typically also include “methods,” which are routines that manipulate the data elements of the object and/or return information about the objects to callers. Objects that represent items within a user's problem domain and that are made visible to the user by a SIM system and that can be manipulated by the user via the SIM system user interface (UI) are sometimes referred to as “design objects” to distinguish them from other objects (referred to as “business objects”) that may not be directly visible to the user but that are, nonetheless, necessary for the model.
Many design objects are made up of other objects. For example, a pipe run may include one or more straight pipe segments, elbows, flanges, gaskets and the like. The pipe run may include two or more nozzles, by which ends of the pipe run may be connected to equipment, such as pumps, tanks, valves, etc. A SIM may expose the pipe run as a design object, which a user can manipulate. For example, the user may stretch, bend, shorten or move the pipe run. However, the SIM may not necessarily expose the individual straight pipe segments, elbows, etc. to the user for direct manipulation. Instead, the SIM may automatically add or remove these objects, or alter their characteristics, such as angle of an elbow, as needed in response to a user's manipulation of a design object.
In another example, a beam may be composed of a single member system and many other objects including: frame connections (representing how the beam is connected to other members at each end), parts (representing the final physical objects), holes (representing connection points along the beam) and other objects. Openings in a beam may be represented by respective additional objects. If an end of a beam is trimmed or notched to fit against column, the trim or notch operation may also be represented by an object. Collectively, a design object and its related objects are referred to as a “design object group.”
Most objects are linked to other objects by means of relationships. Different types of relationships are used in different contexts. For example, one type of relationship is used to arrange objects into a logical hierarchy of “systems.” A different type of relationship is used when a pipe is connected to a nozzle on a piece of equipment. A third type of relationship is used to connect a beam to a column.
Relationships between objects are ordered concepts. A relationship may indicate a logical order in which the corresponding objects were added to a model, which may be different than the order the real-world items will be constructed. For example, when modeling a power plant building, a designer typically establishes a grid coordinate system. The designer then adds columns and places the columns at desired coordinates within the grid system. Later, the designer adds footings under the columns. However, when the power plant is actually built, the footings are constructed before the columns can be put in place on top of the footings.
Another type of relationship between objects is a “functional dependency.” A functional dependency may exist between related objects (an “independent” object and one or more “dependent” objects). When an independent object is changed, all dependent objects are automatically changed as well. In the previous column and footing example, the column is the independent object and the footing is dependent on it. If the column is moved or the weight it must bear changes, the enterprise engineering systems automatically moves the footing or automatically changes its size or weight-bearing capacity as required. In addition, characteristics of any other objects that are dependents of the column are automatically recalculated by the enterprise engineering system. Updating an object, i.e., recalculating one or more of the object's parameters, is sometimes referred to as “recomputing” the object.
As noted, during the modeling phase, a column object is typically added to a model before a corresponding footing object is added to the model. However, when the physical structure (ex., a power plant) is constructed, the footing must be built before the column can be attached to the top of the footing. Thus, the order in which objects are added to a model is not necessarily the same as the order in which corresponding real-world items are constructed or put in place. Similarly, functional dependency relationships do not necessarily indicate the order in which real-world items are constructed or put in place.
Many modern enterprise engineering systems utilize relational databases (RDBs) or other database management systems (DBMSs) to store persistent data structures that represent objects and relationships. For example, RDB records or table rows may be used to store object and relationship data structures.
One particularly useful feature of enterprise engineering systems is the ability to geometrically transform a user-selected object or group of objects. Examples of geometric transformations include moving, rotating and mirroring.
In order to maintain validity and consistency of objects and relationships in a model database, every operation on that database is performed within a database transaction. A transaction has two main purposes: 1) to provide a reliable unit of work that allows for correct recovery from system failures; and 2) to provide isolation between programs accessing a database concurrently. A transaction provides an “all or nothing” proposition. Either all modifications to the database are completed successfully or none are completed.
Thus, to ensure validity and consistency of the model, an enterprise engineering system performs a geometric transformation in a single transaction. The transaction includes three steps. In the first step, the transaction is started and all data structures representing the objects and relationships to be transformed are brought from the database into (real or virtual, collectively referred to as “main”) memory of a computer. In the second step, the objects are transformed in the main memory and all dependent objects are recomputed. Then, in the third step, the (now modified) data structures representing objects and relationships are written back to the database and the transaction is committed.
Many industrial plant models involve very large numbers of objects and relationships, which can pose problems for enterprise engineering systems. A system's main memory must be large enough to simultaneously store all the data structures representing the objects that are to be geometrically transformed and their relationships. As is well known, databases can be much larger than main memories of computers. Therefore, selecting a large portion of a model for a geometric transformation, such as moving a distiller within a petrochemical plant, may cause the main memory capacity of the computer to be exceeded, in which case the transformation cannot be completed.